Field of the Invention
The present invention relates to a method for targeted container virtualization where only separate components of a computer system or a server are virtualized.
Description of the Related Art
Typically, virtualization at an OS kernel level provides for several isolated user spaces—containers. The containers are identical to a real server from a user point of view. Each container has entire OS components except for the kernel. Thus, the applications from different containers cannot interact with each other.
The containers have allocated resource quotes. For example, a hardware node can have thousands of containers running on it. Each of these containers can only use allocated by quota amount of every server resource. The typical resources are: disk space, I/O operations, operating memory, CPU time, network traffic, etc. The containers have their own sets of user groups, processes and devices isolated from the host OS and from other containers. Virtualization provides for isolation and limitation of resources in the containers.
The containers can be migrated to other host servers almost without any interruptions of their services by a “live migration.” The conventional OS-level virtualization solutions are, e.g.: FreeVPS, Icore virtual accounts, FreeBSD Jails, Linux-VServer, OpenVZ, Virtuozzo, Solaris Zones.
Linux kernel with the OpenVZ uses two entities: cgroups (control groups) and namespace. Both of these entities are needed for limiting and controlling the resources allocated for a particular process. For example, a namespace of a network subsystem is a standard network subsystem, a network configuration stack and iptables. The namespaces are created for a memory, for a processor, for a disk and fro all other Linux kernel subsystems. Another namespace can be created on the same host system and the two instances can be used separately. For example, in order to allow a container application to apply its own parameters for working with the network. The application can have large buffers, use sockets and use proprietary configuration setting for iptables.
CGroups is a set of limitations for a set of kernel processes. For example, Apache, PHP, MySQL can be encapsulated into a cgroup. Then, the following limitations can be set: CGroup with a modifier webstack can use not more than 10 GB on aggregate, can use not more than 5 processes per CPU Units, can use not more than 3 MB for site cache, etc. Cgroups allow for allocation of resources, such as CPU time, system memory, network bandwidth, or combinations of these resources among user-defined groups of tasks (processes) running on a system. The cgroups can be monitored and configured. The cgroups can be denied access to certain resources. The cgroups can be reconfigured dynamically on a running system. The cgconfig (control group config) service can be configured to start up at boot time and reestablish the predefined cgroups, thus making them persistent across reboots. By using cgroups, system administrators gain fine-grained control over allocating, prioritizing, denying, managing, and monitoring system resources. Hardware resources can be efficiently divided up among the tasks and the users, increasing overall efficiency.
Virtual Machines (VMs) use hypervisor-based virtualization, where the OS kernel is virtualized for each of the VMs in a form of a Guest OS. Container virtualization uses one instance of an OS kernel of the physical host for all of the containers. Therefore, the containers usually work faster than the VMs, and the density of the containers implemented on one physical machine can be much higher than that of the VMs.
Thus, the containers are widely used by hosting providers. A hoster creates a separate container for each of its clients. These containers are, from the user's perspective, practically identical to a physical server in terms of their functionality. Such containers are also sometimes referred to as Virtual Private Servers (VPS). Typically, the containers are employed by service providers using a cloud-based infrastructure. Complete virtualization of all of the cloud resources is often not needed and can be costly. However, none of the existing systems offer a selected or targeted virtualization of separate cloud components or resources.
For example, a clustered system for storing, searching and processing images may only require launching a couple of processes in a virtual environment for editing client's pictures. In this case, virtualization of a network is not required. Virtualization of a user space and creation of process identifiers (pid) is also not needed. Only the operating memory needs to be virtualized.
Another example requiring targeted (selected) virtualization is a backup service. The backup is limited by a disk capacity, because it takes a large amount of data from one disk and places it onto another disk. Therefore, only the disk space and I/O resources need to be virtualized.
Another example that requires only partial (targeted) virtualization is APACHE web server. The web server provides shared hosting—a number of directories containing web-sites. If the web server needs to open a site upon the http-request, the web-server launches a special process, which serves the http-request by taking data from a certain directory. This process needs to be launched in and isolated environment only using some limited resources. In other words, the entire Linux OS does not need to be virtualized. Only the disk space, I/O, memory and network need to be virtualized. Thus, targeted virtualization (or fragmented isolation) is more efficient than the conventional virtualization such as a conventional system depicted in FIG. 1.
FIG. 1 illustrates conventional container virtualization. The hardware nodes 101.1 and 101.2 can have a plurality of containers 102 implemented on them. Each of these containers has some resources isolated from the host OS 110 and from the other containers. These resources are users and groups 105, system utilities 107, applications 106 and other resources. The resource allocation, isolation and control of the containers are supported by the virtualization layer 109 implemented on the host OS kernel. The host node has hardware components 111 and a network 112. The container 102 can be cloned (103) by creating a copy of the container with a different identifier. Migration 104 of the container 102 includes moving all container files (applications 106, system software 107 and system libraries 108) and its configuration to another node.
FIG. 2 illustrates a conventional schema of container virtualization in more detail. Note that not all (out of about 20) possible virtualization parameters are illustrated. FIG. 2 illustrates different conventional approaches used for isolation of the resources. For example, CPU time is allocated to the container by the hardware node using a special quota. A conventional process planner has two levels. At the first level, the planner decides to which process to give a quant of the CPU time based on a pre-set quota for this container. At the second level, the process planner decides to which process in the given container to give the quant of the CPU time based on standard priorities of the OS kernel (e.g., Linux system).
Setting resource usage limits in the containers is flexible. Therefore, the containers are used in hosting, in developing, testing and running corporate sites. For example, several containers with different configuration can be created on a host and each of the containers can have allocated memory so that the aggregated memory for all of the containers exceeds the memory of the host. Even one container can have allocated memory that exceeds the host memory. Then, if the memory is needed, the memory swap (transfer memory content to the disk) can be used. If the swap is completed, but the memory is still needed, the utility OOM Killer of the host is launched. This utility “kills” the most memory consuming processes in the containers. Thus, the container memory can be controlled in a more flexible manner than a memory of the VMs. When an aggregate memory of the containers exceeds the host memory, this is very convenient for developing tasks.
Likewise, the resources such as disk space, I/O are also allocated to the container according to the corresponding quotas. Some other resources, for example, a network, users and groups, devices, PID tree, IPC objects are virtualized on the container within an isolated space. Other components, such as applications, system software are cloned to on the container. The kernel resources are made available to a container or to multiple containers. In this conventional schema all of the resources are virtualized in the container regardless of the container needs. The container may not need all of the resources as shown in the above examples. Thus, a system, where only resources required by the container are virtualized, is desired.
Accordingly, there is a need in the art for a method for targeted or selected virtualization of components of the containers. Additionally, there is a need in the art for a flexible cloud infrastructure based on more flexible container isolation.